\chapter{Nuestra Propuesta} % (fold)
\label{cha:propuesta}

\section{Definiendo una Arquitectura de Almacenamiento Distribuido}

Harren y su equipo~\cite{harren} propusieron una arquitectura de tres capas:
almacenamiento, DHT y query. Por su parte, Sung et al.~\cite{sung} consideran
que una arquitectura de almacenamiento distribuido debe ubicar o reconocer las
entidades que resuelven 4 preguntas:

\begin{enumerate}
 \item ¿Cómo se identifica el lugar donde se encuentra la información? 
 \item ¿Cómo se solicita esta información?
 \item ¿Cómo se intercambia la información entre repositorios?
 \item ¿Cómo se preserva la consistencia de la información?
\end{enumerate}

En CEPH~\cite{weil} se resaltan tres principios de diseño: desacoplamiento
entre datos y metadatos (no existe una tabla de asignación de archivos, sino
una función que calcula la asignación de manera seudoaleatoria), manejo
dinámico y distribuido de los metadatos  (los servidores de metadatos pueden
variar el espacio de almacenamiento que coordinan, dependiendo de la carga de
trabajo), espacios autónomos y confiables de almacenamiento de objetos (un
dispositivo de almacenamiento de objetos u OSD se compone de un CPU, una
interfaz de red, una memoria cache local y un disco adjunto, se supone que los
OSD se agrupan en clusters que se automonitorean, integran nuevos equipos,
migran contenidos y reparan, en caso necesario).

El diseño de un SAD requiere definir también cual es la entidad o espacio
elemental de almacenamiento. De primera instancia podría pensarse en los discos
asociados con las  computadoras que participan en el sistema. Sin embargo, en
vista de la escala a la que puede crecer y la complejidad de las operaciones
que pueden tener lugar, sería contraproducente asumir una dependencia tan
fuerte sobre dispositivos individuales. Es deseable construir un dispositivo
virtual que exhiba una vida útil más prolongada y un comportamiento más estable
que lo que puede esperarse de un dispositivo físico. En suma, se sugiere la
existencia de una celda o celda de almacenamiento. Esta célula estaría formada
por un conjunto local  de dispositivos sobre los que se impondría una
estructura de control que regule o modere los comportamientos individuales,
usando para ello componentes e información redundante. Se sabe que un conjunto
con estas características puede presentar una interfaz única a través de la que
ofrece capacidad extendida y parámetros de confiabilidad mejorados~\cite{quezada}. 

Se trata de un caso similar al del protocolo TCP, que ofrece un servicio con
garantía de entrega y que, sin embargo, se construye partiendo del protocolo
IP, que no ofrece garantías (lo que se conoce como ``best effort''). La clave de
este comportamiento aparentemente paradójico se encuentra en la aplicación de
recursos redundantes. La confiabilidad se construye sobre la base de la
redundancia. 

En un SAD no solo es importante definir las capas o módulos que implementan los
 requerimientos funcionales, tambien es importante establecer los puntos donde
estos se ubican, la relación entre sitios y, en consecuencia, la gráfica que
emerge de esta red de colaboración.  Se reconoce que en los sistemas complejos,
como es el caso, la estructura juega un papel crítico en la definición de
propiedades tales como: la modularidad, la tolerancia a fallas, la
escalabilidad e, incluso, la rapidez de propagación de la
información~\cite{barabasi, watts}. 

\section{Aspectos a Considerar en el Diseño de un SAD}

\begin{center}
\begin{table}
 \scriptsize
 \begin{center}
  \rowcolors{2}{LightGray}{White}
  \begin{tabular}{ p{3in} c  c  c  c }
   \textbf{Aspecto}         & \textbf{Harren} & \textbf{Sung} & \textbf{Hasan}
   & \textbf{CEPH} \\
   \toprule
   Administración dinámica y
   distribuida de metadatos      & & & & \checkmark \\ 
   Almacenar información         & \checkmark & & & \\ 
   Balance de carga              & & & \checkmark & \\ 
   Consultas via DHT             & \checkmark & & & \\ 
   Control de acceso             & & \checkmark & & \\ 
   Escalabilidad                 & & & \checkmark & \\ 
   Espacios autónomos y
   confiables de almacenamiento  & & & & \checkmark \\ 
   Identificar información       & & \checkmark & & \\ 
   Localización de recursos      & & & \checkmark & \\ 
   Persistencia                  & & & \checkmark & \\ 
   Preservar la consistencia     & & \checkmark & & \\ 
   Seguridad                     & & & \checkmark & \\ 
   Separación Datos - Metadatos. & & & & \checkmark \\ 
   Simetría                      & & & \checkmark & \\ 

  \end{tabular}
 \end{center}
 \normalsize
 \caption{Aspectos a Considerar en el Diseño de un SAD}
 \label{tbl:aspectos}
\end{table}
\end{center}

\begin{table}
 \scriptsize
 \begin{center}
  \rowcolors{2}{LightGray}{White}
  \begin{tabular}{ p{3in} c  c  c  c }
   \textbf{Principio}         & \textbf{Redundancia} & \textbf{Balance de
   Carga} & \textbf{Disponibilidad} \\
   \toprule
   Administración dinámica y
   distribuida de metadatos      & \checkmark & \checkmark & \checkmark \\ 
   Consultas via DHT             & & & \checkmark \\ 
   Control de acceso             & & \checkmark & \checkmark \\ 
   Escalabilidad                 & & \checkmark & \checkmark \\ 
   Espacios autónomos y
   confiables de almacenamiento  & \checkmark & & \checkmark \\ 
   Identificar información       & & & \checkmark \\ 
   Localización de recursos      & & \checkmark & \checkmark \\ 
   Persistencia                  & \checkmark & & \checkmark \\ 
   Preservar la consistencia     & \checkmark & & \checkmark \\ 
   Seguridad                     & \checkmark & & \checkmark \\ 
   Separación Datos - Metadatos. & \checkmark & \checkmark & \checkmark \\ 
   Simetría                      & & \checkmark & \\

  \end{tabular}
 \end{center}
 \normalsize
 \caption{Aspectos a Considerar en el Diseño de un SAD vs. Parámetros de
 desempeño}
 \label{tbl:desempeno}
\end{table}

Luego de revisar los trabajos sobre almacenamiento distribuido de información,
nos dimos a la tarea de reconocer los aspectos mas importantes que hay que
considerar al momento de proponer la arquitectura para un nuevo sistema de
almacenamiento distribuido, dichos aspectos, los identificamos principalmente
en ~\cite{harren}, ~\cite{sung}, ~\cite{hasan} y ~\cite{weil}, y los resumimos
en la tabla \ref{tbl:aspectos}.


\section{Parámetros de Desempeño}

Para convencer a los usuarios sobre la conveniencia de compartir las
capacidades de sus equipos individuales, se requiere exhibir los costos y
beneficios que implica un Sistema de Almacenamiento Distrbuido. El beneficio
inmediato es que se logra un cierto grado de independencia entre la información
y su almacén. Estos parámetros de desempeño y su relación con los aspectos más
importantes del diseño, se ilustran en la tabla \ref{tbl:desempeno}.

Visto de otra forma, los archivos que se guardan en un repositorio colectivo no
dependen de un solo aparato para su recuperación. Si un archivo estuviera
guardado en una sola máquina, entonces la falla de ésta cancelará su
recuperación.  Naturalmente que, si se guardan varias copias del mismo en otras
tantas máquinas, entonces se consigue esta independencia del almacén, pero a un
costo que puede ser excesivo. Los costos de participar en un SAD se determinan
a través de sus parámetros de desempeño~\cite{lazalde}:

\begin{description}

\item[Redundancia]

El propósito de un sistema tolerante a fallas es detectar y, si es posible,
reparar los errores antes de que se manifiesten en la interfaz del usuario. La
clave del diseño consiste en el uso de la redundancia. Este término se refiere
a los recursos adicionales que se incluyen en el sistema, que no se usarán en
una situación perfecta. La redundancia se requiere para enmascarar la falla,
luego que se detecta el error. Se pueden distinguir tres tipos de redundancia:
de recursos fí­sicos, de tiempo y de información. La primera se refiere a la
replicación de los componentes del sistema. La segunda, a la repetición de una
acción de cómputo o de comunicaciones, sobre el dominio del tiempo. Por último,
la redundancia de la información se refiere a una técnica de codificación que
introduce un exceso de dígitos binarios para representar la información. En un
sistema bien diseñado se espera conseguir la máxima protección contra fallas,
usando la menor cantidad de recursos redundantes.  Entonces, la redundancia se
evalúa contabilizando el conjunto de recursos en exceso y comparéndolo con el
número de fallas que con ello se consigue tolerar. 

\item[Balance de Carga]

Se refiere a la cantidad de información que un dispositivo recibe en resguardo,
en relación con el resto de los componentes de almacenamiento. Se necesita
establecer un criterio, ya sea de equidad ó de justicia, para luego medir el
cumplimiento de esta caracterí­stica. La equidad se refiere a asignar,
idealmente, la misma cantidad de información a todos los dispositivos del
conjunto. La justicia, por su parte, se refiere al hecho de asignar,
idealmente, la misma cantidad de información a todos los dispositivos de la
misma capacidad nominal. En este caso se espera que dos componentes idénticos
reciban el mismo nivel de carga, pero se aceptan también las diferencias que
pueden presentarse en un conjunto con capacidades heterogeneas.  En cualquiera
de las circunstancias, el balance de carga se evalúa mediante una estadí­stica
que caracteriza la cantidad de información asignada a los dispositivos. Una
medida de dispersión, como la desviación estándar, describe el grado de
cumplimiento del criterio de asignación ideal. 

\item[Disponibilidad] 

Éste parámetro tiene diferentes medidas a través de las cuales se evalúa. Puede
referirse a la probabilidad de encontrar un recurso cuando se le busca, pero
también implica el tiempo de respuesta medido desde el momento en que se
solicita el documento, hasta el momento en que se entrega al solicitante
(latencia). Puede entendérsele como un indicador de la satisfacción de los
usuarios cuando invocan al sistema buscando recuperar un contenido. Por otro
lado, la calidad de servicio implica un costo asociado con los recursos donde
se almacena la información y con el ancho de banda que se requiere para su
recuperación. No es lo mismo guardar un archivo en un solo punto del sistema y
transmitirlo hasta el lugar donde se requiera, que codificarlo  y guardarlo en
varios puntos. La segunda opción implica que el documento está más disponible,
pero también implica que se han utilizado un mayor número de almacenes para
soportar el mismo servicio. Un SAD debería permitir a cada usuario elegir el
grado de servicio con el que espera recuperar su información.

\end{description}

\newpage

\section{Requerimientos} % (fold)
\label{sec:reqs}

\begin{table}
 \scriptsize
 \begin{center}
  \rowcolors{2}{LightGray}{White}
  \begin{tabular}{ p{3in} c  c }
   & \multicolumn{2}{c}{\textbf{Requerimiento}} \\ \cline{2-3}
   \textbf{Aspecto}         & \textbf{Funcional} & \textbf{No Funcional} \\
   \toprule
   Administración dinámica y distribuida de metadatos & & \checkmark \\ 
   Balance de carga                                   & & \checkmark \\ 
   Consultas via DHT                                  & & \checkmark \\ 
   Control de acceso                                  & \checkmark & \\ 
   Escalabilidad                                      & & \checkmark \\ 
   Espacios autónomos y confiables de almacenamiento  & & \checkmark \\ 
   Identificar información                            & \checkmark & \\ 
   Localización de recursos                           & & \checkmark \\ 
   Persistencia                                       & \checkmark & \\ 
   Preservar la consistencia                          & \checkmark & \\ 
   Seguridad                                          & \checkmark & \\ 
   Separación Datos - Metadatos.                      & & \checkmark \\ 
   Simetría                                           & & \checkmark \\ 

  \end{tabular}
 \end{center}
 \normalsize
 \caption{Aspectos a Considerar en el Diseño de un SAD vs. Requerimientos}
 \label{tbl:requerimientos}
\end{table}

Ya con los parámetros de desempeño bien identificados, podemos inferir cuales
son los requerimientos, tanto funcionales como nó funcionales, a partir de su
relación con los aspectos de diseño mas importantes. tal como se muestra en la
tabla \ref{tbl:requerimientos}.

\subsection{Requerimientos Funcionales}

El diseño de un SAD incluye la formalización de los procesos de tratamiento de
la información y los aspectos arquitectónicos que gobiernan su construcción. 
Estos se traducen en los denominados requerimientos funcionales y no
funcionales del sistema, respectivamente.  

Los requerimientos funcionales definen el comportamiento interno del software:
cálculos, detalles técnicos, manipulación de datos y otras funcionalidades
específicas que muestran cómo los casos de uso serán llevados a la práctica. 
Son complementados por los requerimientos no funcionales, que se enfocan en el
diseño o la implementación~\cite{sommerville}. Utilizando la construcción de
una casa como analogía, los requerimientos funcionales se refieren a las
necesidades del usuario o cliente que la habitará. En tanto, los requerimientos
no funcionales se refieren a los aspectos de diseño del ingeniero o arquitecto
que la construirá. En este sentido, los primeros responden a la pregunta ¿qué
se necesita?, mientras que los segundos responden a la pregunta ¿cómo se
resuelven las necesidades?.

\begin{description}

\item[Monitoreo y control]

Se requiere una entidad del sistema capaz de llevar un control de los
componentes en operación, verificar los parámetros de desempeño del sistema
(balance, redundancia, disponibilidad) e invocar a los mecanismos de regulación
o reparación~\cite{deswarte}, por ejemplo, cuando haya que migrar contenidos de
un disco viejo a un disco nuevo, o cuando el sistema se desvíe de sus
especificaciones.

\item[Metadatos]

Los metadatos son la información a partir de la cual se gestiona la aplicación.
 Son los datos relacionados con los usuarios, sus cuotas, los atributos de
acceso a los recursos almacenados, la localización física de los archivos,
tamaño, relaciones, etcétera. En breve, se trata de una base de datos. Sin
embargo, su diseño incluye decisiones vinculadas no solo con su contenido y
operaciones, sino con su localización. Una BDD centralizada ofrece una
administración muy sencilla, pero puede convertirse en un cuello de botella que
limita la calidad de servicio. En contraste, una BDD distribuida puede ofrecer
un alto desempeño pero, a cambio, se requieren mecanismos de acceso
sincronizado y control de información replicada. 

\item[Consistencia y sincronización]

En un SAD se  necesita definir una política para sincronizar el manejo
concurrente de contenidos, esto quiere decir que  se debe definir de qué forma
se soportan las solicitudes simultáneas de acceso a un mismo recurso. Se pueden
soportar, por ejemplo, varias lecturas simultaneas y una sola escritura. 

Existen archivos, tanto de los usuarios como del propio sistema, que pueden
encontrarse replicados en varios sitios. En estas circunstancias, una operación
de escritura que modifique una réplica deberá repercutirse con el fin de
garantizar la consistencia del conjunto de copias. Luego de este aseguramiento,
cualquier entidad tendría acceso a la misma información, independientemente de
la copia que recibiera. Sin embargo, se presenta una ventana de tiempo durante
la cual el sistema cuenta con al menos dos versiones del mismo archivo. En este
lapso, la falla de algún componente involucrado pondría en riesgo el éxito de
la operación. Las especificaciones del sistema deben incluir, por tanto, la
clase de fallas que pueden tolerarse y los protocolos con los que se les haría
frente, llegado el caso. 

\item[Integridad y confidencialidad]

La información se expone a un medio con limitaciones físicas por el que debe
viajar o almacenarse. Este medio representa una fuente de errores que pueden
modificar los dígitos binarios que componen un archivo. La integridad supone
una garantía para entregar el contenido original, aún en presencia de factores
que pueden degradarlo. Por otro lado, la confidencialidad se refiere a la
garantía de acceder a un archivo y su contenido, solo en los casos que el
usuario que lo solicita tiene derechos sobre el mismo.

Una característica común de los SAD es el uso de la redundancia de información
para proveer tolerancia a fallas y, en particular, integridad. La estrategia
más sencilla consiste en la replicación de archivos. Esta técnica se utiliza
por ejemplo en PAST~\cite{rowstron} y Farsite~\cite{adya}. En estos sistemas,
los componentes de almacenamiento participan con sus capacidades individuales
para guardar réplicas de cada archivo en custodia. En contraste, existen
sistemas como OceanStore~\cite{kubiatowicz} o Intermemory~\cite{chen} en los
que la redundancia se implementa mediante técnicas de detección y correción de
errores, por ejemplo usando códigos de la familia Reed-Solomon, códigos de red,
fuentes digitales, entre otros. En estos casos, cada archivo se transforma en
un conjunto de bloques codificados que luego son alojados en los componentes de
almacenamiento disponibles.

La selección de una estrategia en particular tiene un fuerte impacto en
aspectos operacionales tales como el costo y la administración. Estudios
recientes~\cite{rodrigues} sugieren que cuando los dispositivos exhiben un
comportamiento estable de largo plazo, el sistema puede sacar provecho de una
estrategia conservadora basada en códigos. En tanto, si los dispositivos tienen
un comportamiento intermitente, el sistema debe basarse en una estrategia más
agresiva, usando replicación. También se sabe de estrategias mixtas que
combinan lo mejor de cada opción.

Por cuanto se refiere a la confidencialidad, se trata de dar solución a un
requerimiento de diseño teniendo en cuenta que tanto los usuarios, como el
propio sistema pueden almacenar información sensible y deben disponer de esta
garantía. La información puede quedar expuesta al uso no autorizado ya sea
durante su transmisión, o bien, durante su almacenamiento. En ambos casos se
deben tomar las previsiones que limiten el riesgo. Sin embargo, la
confidencialidad de la información no solo depende de su aseguramiento
criptográfico, se deben considerar los mecanismos que limitan el acceso a la
información dependiendo del rol que cada usuario tiene asignado en una
organización.  

\item[Indexación y búsqueda]

Cada uno de los dispositivos de almacenamiento que participan debe contar con
un identificador único que lo distinga del resto. Esta decisión dota al
conjunto de una estructura a través de la cual es posible definir la posición
donde se guarda un archivo, pero también define la manera de acceder al
dispositivo que corresponde. Los mecanismos tradicionales encontrados en los
sistemas de archivos no parecen adaptarse bien al manejo de volúmenes masivos.
En estos casos se requieren mecanismos ágiles y distribuidos para emplazar y
localizar contenidos. En los sistemas P2P, por ejemplo, se observa que los
algoritmos basados en tablas de dispersión distribuida recuperan información
basándose en un identificador único~\cite{balakrishnan}. Se proporciona el
nombre del archivo que se busca y la función de dispersión lo relaciona con la
posición o identificador del dispositivo en el que se guarda. Sin embargo, para
efectuar las consultas más elaboradas no basta proporcionar el nombre de un
archivo, en muchos casos se requieren consultas semánticas, que se refieren a
conceptos o palabras clave que describen el contenido de un grupo de documentos.

\item[Interfaz de aplicación]

Los usuarios de un SAD podrán dar de alta y baja sus equipos, conectarse,
desconectarse, almacenar archivos, borrarlos, recuperar contenidos usando
diferentes criterios de búsqueda. Por otro lado, cada máquina deberá
interactuar con un conjunto heterogeneo de componentes incluyendo programas
escritos en diferentes lenguajes, diferentes sistemas operativos, diferentes
capacidades de procesamiento y almacenamiento, entre varias posibilidades. Por
lo anterior, es muy importante garantizar que la interfaz de aplicación
facilite la interoperabilidad. Igualmente es importante que la instalación de
las diferentes versiones del SAD repercutan en lo mínimo en las máquinas de los
usuarios finales. Desde esta perspectiva, los usuarios deberían considerarse
como clientes de un servicio. Como en el caso de los abonados del sistema
telefónico, a quienes se les instala un equipo cuando se suscriben y para ellos
resultan transparentes las actualizaciones posteriores o cambios en el sistema
que les da soporte.  

\end{description}

\subsection{Requerimientos No Funcionales}

Los requerimientos no funcionales se refieren a los aspectos de diseño que
gobiernan la definición de las soluciones. A partir de ellos se establecen
criterios y prioridades que se busca atender en el proceso de desarrollo del
software. 

\begin{description}

\item[Modularidad]

Aún faltan estudios concluyentes que definan la mejor manera de resolver o
proveer cada una de las funciones que se requieren en un SAD. Por otro lado,
parece razonable pensar que un sistema de este tipo pueda evolucionar y
encontrar nuevas maneras de proveer las funciones que ya tiene implantadas. Por
lo anterior, un diseño estratégico pasaría por definir estas funciones como
módulos o cajas negras con entradas y salidas bien establecidas, dejando la
posibilidad de variar su construcción, en tanto las interfaces permanezcan sin
cambios.

\item[Interoperabilidad]

La posibilidad de intercambiar información proveniente de distintas fuentes,
sugiere que ésta puede registrarse de acuerdo con formatos diferentes. Ya se ha
mencionado que se trata de una tendencia que cobrará mayor relevancia con el
tiempo. Dependiendo del nivel operativo en el que se aborde el problema, habrá
aspectos particulares implicados en la solución. En todo caso, la
interoperabilidad será posible siempre que  se definan mecanismos
estandarizados para invocar o proveer servicios entre las entidades
involucradas. Se trata de un principio de diseño que complementa a la
modularidad y que cobra mayor relevancia en la misma medida en que crece la
heterogeneidad de los componentes que buscan coordinarse.

\item[Escalabilidad]

Se refiere a la manera en que se planea el crecimiento del sistema. Se entiende
que al aumentar el número de componentes de almacenamiento crece la capacidad
del sistema, pero igualmente pueden crecer los conflictos por el uso compartido
de recursos, comenzando por la designación de los sitios de almacenamiento, los
mecanismos para el emplazamiento y localización de la información, las
políticas de acceso, entre muchos aspectos que deben considerarse. Visto de
otra forma, el problema puede plantearse como una pregunta, ¿cómo pasar de un
sistema basado en una red local, a un sistema del tamaño de la Internet, de
modo que no se degraden sus prestaciones mientras crece? Desde esta
perspectiva, la escalabilidad se puede entender como un principio de diseño que
permite que los sistemas evolucionen de lo sencillo a lo complejo.

\item[Confiabilidad y Tolerancia a Fallas]

La confiabilidad es una garantía de continuidad de los servicios que ofrece un
sistema. Se entiende que un sistema es más proclive a fallas, a medida que
crece su complejidad. Para poder soportar las diferentes garantías de servicio
que ofrece, un SAD deberá contar por un lado, con una entidad que despliegue un
monitoreo continuo de las capacidades del sistema y, por otro lado, de un
conjunto de recursos redundantes a los que pueda recurrirse, cada vez que se
asuma que un componente ha caido en falla y deba intervenirse. Sin embargo, las
fallas que pueden presentarse en un sistema no se reducen a la caída de un
componente que queda fuera de servicio. En algunos casos se presentan
comportamientos intermitentes, erráticos e, incluso, algunos tan sutiles como
los que caracterizan a las denominadas fallas bizantinas. La especificaciones
del diseño deberán considerar las clase de fallas que pueden tolerarse y, en
consecuencia, los mecanismos con los que se deberá hacerles frente.

\end{description}

% section reqs (end)

\section{Definiendo la Arquitectura del Sistema} % (fold)
\label{sec:defarq}

Se propone una arquitectura basada en dispositivos virtuales llamados
\textbf{celdas de almacenamiento}. Cada celda estará integrada por un conjunto
de dispositivos coordinados por un representante. Puede pensarse en cada celda
como una red P2P no estructurada, donde cada dispositivo hace el papel de
supernodo, con mecanismos de búsqueda semejantes a los empleados en Napster
(ver figura \ref{fig:celda}).

\begin{figure}[hb]
 \centering
 \includegraphics[width=0.6\textwidth]{images/celda}
 \caption{
  Celda de almacenamiento integrada por un conjunto de dispositivos coordinados
  por un representante.
 }
 \label{fig:celda}
\end{figure}

La celda funcionará como un dispositivo virtual cuyos supernodos presentan una
interfaz única con la que participan, por su parte, en una red P2P más grande
(ver figura \ref{fig:celdas}), esta vez se trata de una red estructurada, con
mecanismos de búsqueda e indexado como los propuestos por CAN o Chord.

\begin{wrapfigure}{l}{0.5\textwidth}
 \centering
 \includegraphics[width=0.3\textwidth]{images/p2pestructurada}
 \caption{Red P2P estructurada de Celdas de Almacenamiento}
 \label{fig:celdas}
\end{wrapfigure}

%\begin{wrapfigure}{r}{0.4\textwidth}
% \centering
% \includegraphics[width=0.4\textwidth]{images/netcell}
% \caption{Federaci\'on de Celdas de Almacenamiento}
% \label{fig:federacion}
%\end{wrapfigure}
%
%\begin{figure}[ht]
% \centering
% \includegraphics[width=0.4\textwidth]{images/sonnet}
% \caption{Extendiendo la Federaci\'on de Celdas para soportar consultas sem\'anticas.}
% \label{fig:federacion}
%\end{figure}

Por sí misma cada celda es un sistema de almacenamiento distribuido que cubre
todos los requerimientos tanto funcionales, como no funcionales requeridos;
desde este punto de vista consideramos que las máquinas de los usuarios
finales, vistas como vistas como nodos, pueden contribuir con sus capacidades
de almacenamiento y procesamiento, mientras  que el representante de la celda
adume las demás funciones. Alternativamente, éste puede delegar algunas
funciones en un conjunto de nodos especializados, como la codificación o el
cifrado, como se muestra en la figura \ref{fig:expansion}. 

\begin{SCfigure}
 \centering
 \includegraphics[width=0.4\textwidth]{images/celdaext}
 \caption{
  En la figura se muestra una celda de almacenamiento conformada por un
  representante y varios supernodos, está celda ofrece la posibilidad de
  incrementar sus capacidades agregando ``nodos flotantes'' que aporten sus
  recursos de almacenamiento.
 }
 \label{fig:expansion}
\end{SCfigure}

Este enfoque dual, de red P2P no estructurada en un contexto local,  y de red
P2P estructurada en un contexto global, abre la posibilidad de ofrecer varios
tipos de servicios de almacenamiento que puede clasificarse en dos grandes
categorías: locales y remotos. Evidentemente, cada servicio trae implicados
diferentes niveles de redundancia. 

En un SAD se requiere encontrar un punto de equilibrio entre el costo de las
comunicaciones y la disponibilidad de los datos. Para sistemas pequeños o
medianos, el dispositivo de almacenamiento se encuentra en la vecindad de la
fuente donde se origina la información y donde se consulta. Sin embargo, para
un sistema de mayor escala, el almacenamiento puede resultar muy caro cuando la
``bodega'' se encuentra lejos del sitio donde se requiere la información.  En
este sentido el almacenamiento local puede proveer, entre otras
funcionalidades, de una ``memoria'' caché. En tanto, el almacenamiento remoto
sirve para proveer un servicio fuera de sitio. El primero garantiza la
disponibilidad de la información de corto plazo. En tanto, el segundo soporta
una disponibilidad de largo plazo. La combinación de ambos sería el principio
de un mecanismo de aseguramiento de la continuidad de los negocios (business
continuity plan). Por su parte, cada celda quedaría a cargo de vigilar las
condiciones locales del balance de carga. 

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.8\textwidth]{images/referencia}
 \caption{Arquitectura de Referencia Tomada de ~\cite{sung}}
 \label{fig:arqreferencia}
\end{figure}

Para satisfacer todos los requerimientos, que el sistema tenga un rendimiento
aceptable en términos de los parámetros de desempeño y dotarlo de la mayor
flexibilidad posible, optamos por un diseño modular, que dependiendo de la
funcionalidad que se requiera de cada nodo, dichos componentes puedan existir o
no, se combinen o bien, sean implementados por un nodo especializado para tal
fin. Pariendo de estas restricciones, tomamos como punto de partida, la
arquitectura de referenciaestudiada en ~\cite{sung}, que se muestra en la
figura \ref{fig:arqreferencia}.

Partiendo de la arquitectura de base (figura \ref{fig:arqreferencia}), y en
función de los requerimientos presentamos, después de algunas semanas de
análisis, una arquitectura que llamamos ``preliminar'' en la cual ya se
contemplan componentes específicos para satisfacer características como la
redundancia, el manejo de: fallas, índice, caché y metadatos, así como las
interfaces de comunicación hacia la red, el usuario y aplicaciones externas
(ver figura \ref{fig:arqpreliminar}).

\begin{figure}[hb]
 \centering
 \includegraphics[width=0.8\textwidth]{images/preliminar}
 \caption{Arquitectura preliminar}
 \label{fig:arqpreliminar}
\end{figure}

Sin embargo, hubo aspectos que no quedan muy bien definidos en la arquitectura
preliminar (figura \ref{fig:arqpreliminar}), que se detallan mejor en nuestra
propuesta final (ver figura \ref{fig:arqpropuesta}), de entre los que destacan,
las interfaces que incluye el diseño para delegar responsabilidades a
componentes independientes e incluso externos al sistema, como es el caso del
manejo de metadátos, o de índices basados en DHT\footnote{\textit{Distributed
Hash Tables}}, además de expresar explícitamente que la interfaz de usuario
quedará completamente desacoplada con el núcleo del sistema y que el acceso a
consultas tanto libres como sensibles a la semántica será a través de una
intefaz de programación de aplicaciones.

\begin{figure}[hb]
 \centering
 \includegraphics[width=0.8\textwidth]{images/propuesta}
 \caption{Arquitectura propuesta}
 \label{fig:arqpropuesta}
\end{figure}

% section defarq (end)

% chapter propuesta (end)
